Defining this to include all zero-conf funds means that an adversary will be able to arbitrarily inflate it above the realistic balance, as soon as we implement detection of zero-conf funds.

If I send you funds in a bunch of transactions that each have 50 unpaid actions and expire at the next block, I can be pretty confident that at most one (probably zero) of them will be mined. So, using this value as defined for anything opens the wallet up to the transparent equivalent of a Faerie Gold attack (and to various social engineering attacks, such as refund scams, if it is ever shown to a user). This is also a potential DoS attack on auto-shielding.

I agree that we haven't yet implemented the things that would enable these attacks, but still, it should not be defined that way.

Zero-conf balances have essentially become the standard among zcash (and Bitcoin and Ethereum) wallets, and the functionality to provide zero-conf balance is highly in demand. I don't know how we get around that; users in general would prefer to immediately see incoming funds as being recognized, at the cost of having to be diligent about waiting for important transactions to be mined.

We spent a huge amount of time, effort, and protocol complexity preventing Faerie Gold attacks. I don't see why we would just throw up our hands and accept a transparent attack with similar impact because not caring about it is "the standard".

What do Bitcoin and Ethereum wallets do these days about minimum-relay-fee transactions that definitely won't get mined? Are you really saying they just show them as balance anyway?

There is a slight issue here regarding notes that are just about to expire. Without the max(_, 1), with min_confirmations == 0 this would set summary_height to the "mempool height" (chain_height + 1), which is precisely what we want for any transaction in the mempool (that still has a chance of being mined, and thus mined before expiry). Down below in the note selection code, we exclude transactions that have expired as of summary_height (because expiry_height < summary_height) from the balance, which means if someone calls this API with min_confirmations == 0, then about-to-expire funds will disappear from the wallet balance, only to reappear again if the transaction does actually get mined in the last block it can.

I'm fine with this being an edge case we don't handle yet, and instead merging @daira's suggested comment change that we treat min_confirmations == 0 as min_confirmations == 1 for shielded notes.

Let's file an issue so that we don't forget this.

Filed as #940.